One of a number of challenges facing the software industry is serviceability of production code. System code shipped to a customer is generally optimized for maximum performance, but not for serviceability. This configuration may present challenges when customers report code problems. It is generally a long process to get serviceable code onto their system so that software support personnel can proceed in diagnosing the problem. The contemporary process typically begins by first having the customer recreate the problem. Then, the software supplier is contacted and support personnel then notifies development personnel. The development personnel then provides serviceable code for the given release and service pack level for the customer's system. Development personnel also try to anticipate which system programs will need to be serviceable (debuggable) when installed onto the customer's system. Next, the customer needs to be willing to stop production or otherwise free up their system while the serviceable code is loaded onto the system. This can sometimes take days for a window of opportunity to open, and often results in waiting for a weekend.
Once serviceable code is loaded, the code to be replaced is often linked to pre-started jobs, so just replacing the system code with the serviceable code itself will not start the serviceable code unless or until the pre-started jobs are restarted. In some situations, the restarts may not be simple and may require identifying subsystems and the savvy to know which jobs to restart. Then, when the serviceable code is finally applied and being called by the jobs of interest, the software development personnel may have anticipated incorrectly and may need to determine which additional serviceable code needs to be generated and applied on the system in order to continue the debug, potentially having the whole cycle repeated.
Additional challenges when trying to service code on a customer system may also occur when the code does not have appropriate levels of debug data, or when developers may need to debug code in areas, which were initially unforeseen. In these situations, the user may be actively using the program and have the program in a preferred state. These users would be reluctant to end the debug session, recompile or re-apply the program with debug data and start over. Rather, these users would prefer that service personnel simply start debugging the program of interest at the current location without stopping their application.
Therefore there is a need in the art to reduce the time and disruption when servicing production code on customers' systems.